BLUE-271 fix: applyTimestamp added to processed tx #76
Conversation
achal-singh
force-pushed
the
applyts-processedTx
branch
from
1cf2262
to
99b835d
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
src/Data/Data.ts
Outdated
| // Send ehlo event right after connect: | ||
| socketClient.emit('ARCHIVER_PUBLIC_KEY', config.ARCHIVER_PUBLIC_KEY) | ||
| archiverKeyisEmitted = true | ||
| Logger.mainLogger.debug(`✅ New Socket Connection to consensus node ${node.ip}:${node.port} is made`) |
Check warning
Code scanning / CodeQL
Log injection Medium
jairajdev
force-pushed
the
applyts-processedTx
branch
from
99b835d
to
8d8b671
Compare
jairajdev
changed the title
| @@ -1157,7 +1157,7 @@ export const storeAccountData = async (restoreData: StoreAccountParam = {}): Pro | |||
| txId: receipt.data.txId || receipt.txId, | |||
| cycle: receipt.cycleNumber, | |||
| txTimestamp: receipt.timestamp, | |||
| txApplyTimestamp: null, | |||
| applyTimestamp: receipt.timestamp, | |||
There was a problem hiding this comment.
@jairajdev what's the difference b/w applyTimestamp and txTimestamp ? both are receiving the same value ..i.e. receipt.timestamp and also what's the reasoning behind renaming applyTimestamp from txApplyTimestamp? I hope it won't break the other flow! in archive-server
There was a problem hiding this comment.
txTimestamp is the timestamp set before putting the tx in the tx queue
txApplyTimestamp is the timestamp when the tx is processed/consensused
but in this storeAccountData function which was used to restore the tx receipt from the first node in the network ( this feature is not used anymore ), since there is no way we can calculate the txApplyTimestamp, we have to set the txTimestamp.
There was a problem hiding this comment.
but what's the need to have 2 fields receiving the same value.. if applyTimestamp value can't be correctly calculated and inserted, why shouldn't it be removed ? what's the purpose of having this extra field then ? @jairajdev
Summary
applyTimestampwas not set correctly in case of processed transaction logic, this PR fixes that.